1. Technical Field of the Invention
The present invention relates in general to the telephony field and, in particular, to a method and system for minimizing the effect of replacing central processor programming languages in telephony systems.
2. Description of Related Art
There are numerous new design requirements being imposed on manufacturers of digital switching systems. For example, there are many new programming languages being required for use in digital switching system central processor software applications, in addition to very high capacity switch requirements. These new programming language requirements are being imposed on the manufacturers by both the telecommunication system operators that purchase the switching systems and the manufacturers themselves. As such, there are numerous and different new programming language requirements being imposed on digital switching system designs for different software applications, different customers, and also different business entities within the manufacturers"" own organizations.
The primary reasons for these new programming language design requirements are the stringent time-to-market development and manufacturing constraints being imposed, the ability to purchase source code for certain software applications, and the fact that the existing switching system central processor programming languages are simply out-of-date. For example, the well-known PLEX programming language has long been in use for central processor software applications in the present generation of digital switching systems, such as in the AXE Digital Switching Systems manufactured by Ericsson Telecom AB.
Generally, in most software applications, the use of more modern programming languages can reduce the number of source code statements required per task, which in turn can reduce software development time, support costs, and costs for error corrections and other changes. However, as mentioned earlier, a significant amount of existing digital switching system software has been written in the xe2x80x9colderxe2x80x9d (e.g., PLEX) programming languages, and many of these programs have been in development over very long periods of time. As such, there can be an enormous amount of staff-hours and related costs already invested in the development of these programs. Consequently, it would be highly impractical for many reasons (e.g., cost, reliability, delays, etc.) to replace the existing programs with programs re-written in one or more new programming languages. Therefore, a scheme is needed to replace current application software (e.g., programs written in PLEX) on a per program unit basis, while retaining the basic mechanisms needed for interoperability between the hardware units and software modules.
Preferably, any scheme used for replacing the existing software should form part of an organization""s normal support process flow for creating new software and/or updating existing software. Furthermore, such a software replacement scheme should consider the fact that future telecommunications systems will be required to be more heterogeneous with respect to the programming languages being used. In other words, the days of meeting customer requirements for single programming languages used in all applications and all processor environments are gone.
The Capacity Modular Control (CMC) System is the newly developed version of the multi-central processor (multi-CP) AXE 10 Digital Switching System manufactured by Ericsson Telecom AB. The main purpose of the CMC System is to interconnect several CPs, which enables them to share the processing load and thereby increase the overall system capacity. A simplified block diagram of an exemplary CMC System (10) is shown in FIG. 1A. As shown, the individual CPs 12, 14, 16 are coupled together via an Inter-Processor Network (IPN) 18. The IPN also couples other types of processors together, such as the pair of Adjunct Processors (APs) 20, 22 shown.
Typically, a telephony system CP has three main components: (1) an executing processor; (2) a program and data store; and (3) a scheduling unit. For example, referring to FIG. 1B, each CP 12 (14, 16) in a CMC System includes an executing processor 24, which executes instructions for both the application programs and operating system. Each CP also includes a program and data store 26 that is subdivided into different parts, each of which supports a known hardware entity or software function, such as job-handling, variable-handling, memory caches, etc. A scheduling unit 28 is also included in each CP, which schedules jobs in the correct order for the executing processor 24, and also communicates with other processors that support communications with peripherals and other processors in the system, such as, for example, with Input/Output Group (IOG) 30 or Regional Processor (RP) 32 via an RP Bus (RPB) 34.
A problem with conventional and more recently developed central processor schemes (e.g., CMC) is that an executing processor in each CP (e.g., 12, 14, 16) executes applications in only one programming language. Also, as illustrated by the CMC scheme, each executing processor is associated with only one program and data store and scheduling unit. Consequently, in order to update or replace an existing programming language, the application software has to be rewritten for the same executing processor, or the application has to executed by a different executing processor in a different CP. Therefore, when combining different types of executing processors, some of them are likely to be only partly utilized. Furthermore, when a multi-CP system (e.g., CMC) is utilized for increased capacity, an operator has to allocate software to the different CPs in order to maximize the system""s capacity. However, in this case, the communication path between CPs acts as a bottleneck.
U.S. Pat. No. 5,452,456 to Mourey et al. describes an approach that uses different instruction sets for different parts of a program. As such, the main purpose of the approach described in the Mourey patent is to utilize a new processor architecture without having to recompile all of the software. However, the Mourey approach of using different languages in one program is not as efficient as an approach that would use one compiler and software architecture for the same programming language and source code. As described in detail below, the present invention takes such an approach and also successfully resolves the above-described problems.
The preferred embodiment of the present invention provides a separate executing processor for each programming language in each CP. As such, each CP in a multi-CP system utilizes a common program and data store and scheduling unit, which support two or more executing processors. Each executing processor can execute a different application using a different programming language. Consequently, applications using older programming languages can be executed by the CPs, in addition to the same or different applications being executed with new programming languages.
An important technical advantage of the present invention is that each executing processor can be more efficiently if not completely utilized.
Another important technical advantage of the present invention is that maximum capacity can be obtained from a single program and/or data store.
Yet another important technical advantage of the present invention is that the executing processors are more language-specific than the scheduling units and program and data stores, which allows the use of specialized hardware support and places special demands on the executing processors to operate more efficiently. The hardware support can be for sub-variable accessing, functional changes, file size alterations (e.g., for PLEX), fast context switching, function calls and efficient access to function-local data (e.g., for Erlang), inheritance support, pointer manipulation and garbage collection (e.g., for Java), etc.
Still another important technical advantage of the present invention is that for each high level language being executed, an appropriate assembly language can be used to reduce the source code volume, which reduces the bandwidth demand for program store reads, the demands on the cache volume, and the overall cost of the program.
Still another important technical advantage of the present invention is that an executing processor used can be either off-the-shelf (out-sourced) or custom designed. For a common sourced processor, it is possible to purchase higher quality compilers, debuggers, etc.
Yet another technical advantage of the present invention is that it is possible to combine program language flexibility (relatively easy to change from one programming language to another) with higher system capacity and overall cost-effectiveness.